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Method for installing and configuring software components 

The present invention relates to a method for the 
automatic installation and configuration of software 
5 components in a computer network which comprises a plurality 
of client computers and at least one network resource of 
installable software components. The invention furthermore 
relates to computer program objects for carrying out this 
method in the form of a rule package, a framework and a client 
10 program, and to computers and data storage media which are 
programmed with such program objects. 

The distribution, installation and configuration of 
software components in relatively large computer networks, for 
example corporate networks with thousands of different client 
15 computers running hundreds of software components, some of 
which are moreover to be differently configured, is in 
practice a non-trivial problem. 

The most varied mechanisms have been proposed for solving 
this problem, see in particular: 
20 - "Software Distributor Administration Guide for HP-UX Hi, 

Edition 3", Hewlett-Packard Company, June 2002, 

http: //docs .hp. com/hpux/pdf /B2355-90754 .pdf ; 

Bailey, E. C. : "Maximum RPM - Taking the Red Hat Package 

Manager to the Limit", Red Hat Software, Inc., June 1998, 
25 http : / / www . rpm. org/ local/maximum- rpm. ps . gz ; 

Jackson, I., et al.: "Debian Packaging Manual, Version 

3.2.1.0", 24 August 2000, 

http://www.sylence.net/stuff/Debian Packaging Manual.pdf ; 
and furthermore : 

30 - Franken, K. : "Using RPM-SuperVisor , vl.ll", 6 Nov. 2001, 

http: //www. klaus . franken.de/rpmsv/download/rpmsv.pdf ; 
"Safe Mechanism for Installing Operation System Updates 
with Applications", IBM Technical Disclosure Bulletin, IBM 
Corp. New York, US, vol. 41, no. 1, 1998, pages 557-559, 

35 ISSN: 0018-8689; 
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Microsoft 



Corporation, 

http : //download. microsoft . com/download/ f/7/7/ 
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1999, 
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5 In all known solutions, installation of the software 
components on the client computers is always initiated from a 
central network resource. To this end, in the simplest case, 
the software components, possibly together with assigned rule 
packages, which contain instructions for the installation of 

10 the particular software component (s ) , are sent to the client 
computer (central "push" distribution of software) , which 
occupies high levels of network bandwidth, even if individual 
software components are not actually required on certain 
client computers. Improved solutions distribute in a first 

15 step update lists with references to software components to be 
retrieved from the central network resource to the client 
computer or provide such lists for retrieval (central update 
lists, "push" or "pull" distribution) ; the software 
components, optionally together with or integrated into rule 

20 packages for the installation thereof, are then again sent to 
the client computer. 

Both known systems have major disadvantages. In the first 
case, it is necessary to have precise knowledge regarding the 
equipment and requirements profile for all client computers in 

25 the field, which entails compiling and administering 
comprehensive directories and distribution keys. The second 
case also involves a central distribution strategy which 
cannot respond to rapid in situ changes to the client 
computer's hardware or software, such as the connection of new 

30 hardware, logging onto a network, logging on of a user etc. 
which, under certain circumstances, may entail not only 
reinstallation, but also reconfiguration of software 
components . 



35 desirable to provide a solution for the installation and 



The invention is based on the recognition that it would be 



configuration of software components in a computer network of 
many different client computers, which solution is capable of 
responding and reacting to individual requirements and current 
changes of state of each individual client computer. 
5 Said object is achieved in a first aspect with a method of 

the- above-stated kind which is distinguished according to the 
invention by the steps: 

a) provision of a framework on the network resource 
which comprises a rule package for each of the installable 

10 software components of the network resource and a list of rule 
packages to be run, but not the software components 
themselves, 

wherein at least one of the rule packages comprises a 
routine for loading its software component from the network 
15 resource and installing it on a client computer and at least 
this or one of the other rule packages comprises a routine for 
configuring its software component installed on a client 
computer, 

b) transferring the entire framework to a client 
20 computer; and 

c) running the list of rule packages with installation 
routines to be run on the client computer, calling their 
installation routines, and again running the list of rule 
packages with configuration routines to be run on the client 

25 computer, calling their configuration routines, 

wherein at least step c) is triggered by a local event on 
the particular client computer, preferably by a system startup 
or shutdown, system lock or share, user logon or logoff, 
network logon or logoff, program startup or shutdown, 

30 connection or disconnection of hardware or by a timer. 

In this way, it is for the first time possible to achieve 
fully automatic, decentralised and dynamic self installation 
and configuration of each individual client computer in a 
manner which is capable of responding rapidly to local events. 

35 Since the entire framework with all potentially necessary rule 
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packages is always available to each client computer, local 
events and changes of state of the client computer may be 
directly converted . into corresponding software component 
installation or configuration operations, each client computer 
5 being autonomous to the greatest possible extent. 

Using the method of the invention it is for the first time 
possible not only to distribute and install of software 
components, but simultaneously also to configure them, i.e. to 
set specific parameters of the installed software component. 

10 As a result, user-specific, application environment-specific, 
group-specific or alternatively simply standard corporate 
configurations can be implemented on all client computers in 
the network. All that is required for this purpose is a one- 
off definition of a rule package for each software component. 

15 This is also the first time that the problem has been 

recognised and taken into account that correct configuration 
of the individual software components is only possible once 
the installation of all software components is complete, as 
installation operations often have the side-effect of 

20 overwriting the configuration of underlying software 
components. Because all the installation routines are 
initially run in a first pass and then all the configuration 
routines are run in a second pass, correct configuration of 
all the software components is ensured. 

25 One particularly preferred embodiment of the method 

according to the invention, in which successful installation 
of a software component on a client computer may have as a 
prerequisite the presence or absence, configuration or 
deconf iguration of another software component, is 

30 distinguished 

in that, in step a) , the framework comprises a detector 
for each possible prerequisite and at least one of the rule 
packages comprises a routine for deinstalling its software 
component from a client computer and at least this or one of 

35 the other rule packages comprises a routine for undoing 
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(deconf iguring) the configuration of its software component on 
a client computer, and, 

in that, in step c) , if in the course of a rule package it 
is established by means of a detector that the presence or 
5 absence, configuration or deconf iguration of another software 
component is necessary, the installation or deinstallation 
routine, configuration or deconf iguration routine of the rule 
package assigned to this other software component is called. 

In this way, autonomous rule packages are created which 

10 are exclusively referenced by their interdependencies . The 
framework provides reusable detectors for this purpose, by 
means of which the prerequisites for installation or 
configuration of a software component on the client computer 
may rapidly be verified. On the one hand, this facilitates 

15 definition of the rule packages for provision of the 
framework, on the other hand, the rule packages need only be 
run one after the other on the client computer, it also being 
possible for them to call one another in accordance with their 
dependencies. Each rule package itself "knows" how it can 

20 install, deinstall, configure or deconf igure its assigned 
software component. There is no need to produce specific 
installation or configuration scripts for the individual 
client computers . 

A further preferred embodiment of the method of the 

25 invention is distinguished in that the framework also 
comprises detectors for a client computer's hardware or 
operating system and, in the course of a routine, it is 
verified by means of such a detector whether the client 
computer is suitable for the particular installation, 

30 deinstallation, configuration or deconf iguration of the 
software component, and/or that, in the course of a routine, 
it is checked in advance whether the particular installation, 
deinstallation, configuration or deconf iguration of the 
software component has already taken place on the client 

35 computer and, if so, the routine is immediately terminated. 
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As a consequence, each rule package becomes still more 
autonomous, i.e. it also "knows" whether it is relevant or 
applicable to the particular client computer. Running the rule 
packages on the client computers consequently becomes still 
5 more straightforward. In the most general case, all the rule 
packages present in the framework may for example simply be 
run, starting with the first, and each rule package decides 
for itself whether it need be executed at all or whether it 
should call other prerequisite rule packages. 

10 Step b) and/or step c) may preferably also be triggered by 

a remote event on the network resource, for example the 
transmission of a group or broadcast message etc., by which 
means the method according to the invention can reproduce the 
behaviour of conventional central distribution methods. 

15 The invention also extends to a computer program which 

implements the method according to the invention. 

One further aspect of the invention consists in the 
creation of a rule package as defined in claims 7 to 12 which 
is executable on an operating system of a client computer. 

20 Reference is made to the above explanations relating to the 
method with regard to the features and advantages of the rule 
package according to the invention. 

A preferred embodiment of a rule package of the invention 
is distinguished in that it contains at least one trigger 

25 reference to a local event on the client computer or a remote 
event on the network resource, wherein the trigger reference 
assigns at least one of the routines of the rule package to 
this event. As a consequence, individual rule packages or 
their routines may also be executed in event-controlled 

30 manner, so substantially increasing the flexibility and 
responsiveness of the system. 

In practice, new software components are constantly 
appearing on the market. If no special measures are taken, the 
number of rule packages in the framework would constantly 

35 increase; on the other hand, rule packages in the framework 
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become obsolete, for example when software components are 
withdrawn from service. Such obsolete rule packages are 
conveniently removed from the framework, but they may still be 
required on individual client computers, for example due to 
5 outdated hardware components. It is thus particularly 
favourable if rule packages can also be put in an inactive 
state in which only their deinstallation routine can be 
called. In this way, the installation of outdated software 
components can be prevented, while their deinstallation is 
10 possible at any time. 

The invention also extends to a computer which is 
programmed with at least one rule package according to the 
invention. 

One further aspect of the invention is a framework as 

15 defined in claims 14 and 15 which may be provided on a network 
resource in a computer network for a plurality of client 
computers and which contains rule packages according to the 
invention. Reference is made to the above explanations 
relating to the method with regard to the features and 

20 advantages of the framework. 

The invention also extends to a computer and a machine- 
readable data storage medium which are prograinmed with a 
framework according to the invention. 

Still one further aspect of the invention consists in the 

25 creation of a client program as defined in claims 18 to 23 
which is executable on a client computer and contains a 
framework according to the invention. Reference is made to the 
above explanations relating to the method with regard to the 
features and advantages of the client program. 

30 According to a preferred embodiment, the client program 

comprises a local database which contains a list of rule 
packages with installation routines which have run 
successfully and a list of rule packages with configuration 
routines which have run successfully. Running of the rule 

35 packages may be accelerated with the assistance of this 
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database, since, for example for those software packages which 
have already been installed or configured, the corresponding 
rule packages need not be called. 

This furthermore makes it possible for the client program 
5 to compare the rule packages entered in the lists with the 
rule packages contained in the framework and, for those rule 
packages which do not appear in the framework, to run their 
deconf iguration routines in a first pass and their 
deinstallation routines in a second pass, whereby obsolete or 

10 outdated software components may automatically be removed. 

According to a preferred embodiment of a client program 
which makes use of rule packages with trigger references for 
event-controlled execution, the client program monitors the 
occurrence of a local event on the client computer, 

15 particularly preferably a system startup or shutdown, system 
lock or share, user logon or logoff, network logon or logoff, 
program startup or shutdown, connection or disconnection of 
hardware or response of a timer, and/or the occurrence of a 
remote event on the network resource, particularly preferably 

20 the transmission of a group or broadcast message, and calls 
the corresponding rule package routine which is assigned via 
the trigger reference to said event. This may conveniently 
also proceed with the assistance of the lists in the database, 
into which the trigger references of the rule packages may 

25 also be entered. In this way, individual rule packages or 
groups of rule packages or their routines may be executed in 
event-controlled manner. 

In any event, it is particularly favourable for the client 
program to comprise a transaction system for each system- 

30 modifying component, in particular for the rule packages. As a 
result, the system can be rolled back at any time, if for 
example an installation or configuration fails, as is known in 
the art. The operating reliability of the client program is 
substantially increased as a consequence. 
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Finally, the invention also extends to a computer which is 
programmed with a client program according to the invention. 

The invention will be explained below with reference to 
exemplary embodiments shown in the drawings, in which: 
5 Fig. 1 is a block diagram of a computer network in which 

the method, the program objects and computers of the invention 
are used, 

Fig. 2 is a block diagram of an example client computer of 
the invention programmed with a client program, 
10 Fig. 3 shows the schematic structure of a framework of the 

invention. 

Fig. 4 shows the schematic structure of a rule package of 
the invention, 

Fig. 5 shows the interrelationships of several example 
15 rule packages in the form of a relationship diagram. 

Fig. 6 shows a flow chart of the method of the invention. 
Fig. 7 shows an example of the entries in the local 
database generated by an installation routine. 

Fig. 8 shows an example of entries in the local database 
20 generated by a configuration routine. 

Fig. 9 shows several possible types of triggering for the 
steps of the method of the invention running on the client 
computer in the form of a flow chart, and 

Fig. 10 shows the block diagram of a possible 
25 implementation of the client program on an operating system 
with execution layers isolated from one another. 

Fig. 1 shows a computer network 1 which comprises a 
plurality of client computers 2 . An example client computer 2 
is shown in detail in Fig. 2 and contains a number of 
30 schematically represented software components BSl, A, B, etc., 
which, depending on the area of use of the client computer 2, 
are to be installed and configured in computer-, user- or 
application-specific manner. 

The complete set of all software components which are 
35 potentially installable on the client computer 2 is denoted SW 



-lo- 
in Fig. 2. It must be borne in mind here that the installation 
and configuration of the software components SW may be subject 
to complex interdependencies . For example, the installation of 
software component B requires prior installation of software 
5 component A and this in turn requires prior installation of 
software component BSl, which may, for example, already be 
installed on the client computer 2 because it is part of the 
operating system. On the other hand, there may be software 
components which absolutely require the absence, i.e. 
10 deinstallation, of another software component in order to be 
correctly installed. Such a situation is shown in Fig. 5 
(which will be discussed in greater detail below) , wherein the 
paths between software components marked "restrict" indicate 
that absence of a software component is a prerequisite, while 

w 

15 those marked "require" indicate that the presence of a 
software component is a prerequisite. 

It will be understood that the term "software component", 
as used here, depending on the particular case and 
requirements, comprises any kind of granularity or "grain 

20 size" of software, whether a driver, a subprogram, a program 
object, a main program, a subclass or main class, an 
application, or application complex. This reveals the power of 
the solution presented here: a rule package RPi for the 
generally known software component "Microsoft Office XP with 

25 Microsoft Frontpage, without network support" may, for 
example, be defined and at the same time a further rule 
package RP2 for the partially overlapping, partially 
subordinate software component "Microsoft Frontpage, with 
network support". 

30 To return to Fig. 1, the entire relation system of all 

software components SW which may potentially be installed on 
the client computers 2 is shown in the form of a framework FW, 
the structure of which is explained in greater detail below 
with reference to Figs. 3 and 4. The framework FW is provided 

35 in the computer network 1 on a network resource RESi. 
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Independently of the framework FW, all potentially 
installable software components SW (BSl, B, etc.) are 

provided in the computer network 1 on a further network 
resource RES2. 

5 It will be understood that the network resources RESi and 

RES2 may also be one and the same network resource RES (see for 
example Fig. 2) or may themselves be divided into 
geographically distributed network resources (see for example 
the distribution of software components A and B among the 

10 network resources RES2 and RES3 in Fig. 2) . It is also possible 
for one of the network resources, in particular the one for 
the software components, actually to be an "offline" data 
storage medium is, for example a CD-ROM etc. , as is indicated 
by way of example in Fig. 2 for software component B. 

15 The framework FW is developed and maintained, i.e. 

introduced into the network resource RESi, at administrator 
workstations 3. Distribution or propagation of the framework 
FW in the computer network 1 down to the client computers 2 
may proceed in any desired manner, for example using "push" 

20 methods, such as broadcast or group messages using the 
Internet protocol, or "pull" methods, such as retrieval by the 
client computer 2 from logon shares on the network resources 
at system startup or user logon, by peer-to-peer propagation 
or replication methods etc.. 

25 For example, the framework FW may be replicated by 

mirroring and so distributed in the manner of Internet Domain 
Name Services from network node, such as the network resource 
RESi, to network node, such as the network resource RES2 . In 
this manner, the framework FW may also be available on network 

30 resources RES2, the purpose of which is to provide software 
components SW, or also be replicated directly from client 
computer 2 to client computer 2 ("peer-to-peer") . In order to 
keep network traffic at as low a level as possible during 
distribution of the framework FW, it is also possible to 

35 provide that, after an initial distribution of the entire 
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framework FW, only differential updates of the framework FW to 
its latest version are subsequently distributed. 

The further description of the invention assumes a state 
in which the framework FW is available to the representatively 
5 described client computer 2 . 

The structure of the framework FW is explained in greater 
detail with reference to Figs. 3 and 4. According to Fig, 3, 
the framework FW comprises a set of rule packages RP, 
specifically one rule package RP for each software component 

10 BSl, A, B, etc. which is potentially installable and/or 
configurable on a client computer 2. Each rule package RP is a 
representation of the hard- and software requirements of one 
particular software component . 

Fig. 4 shows the structure of an example rule package RPa 

15 for software component A. The rule package RPa contains a 
reference RESa to its assigned software component A, for 
example in the form of a pointer to the particular network 
resource RES2 on which the software component A is available. 

According to Fig. 4, each rule package RP comprises a 

20 routine "INSTO" 4 for installing the software component 
assigned to it (in this case A) on the client computer 2, a 
further routine "DEINSTO" 4' for deinstalling this software 
component from the client computer 2, a routine "CONFIGO" 5 
for configuring this software component and a routine 

25 "DECONFIGO" 5' for undoing ( "deconf iguring" ) the 
configuration of this software component. 

A rule package RP need not contain all four routines A, 
4', 5, 5', but must contain at least one of the routines 4, 
A', b, 5'. The rule package RP preferably contains at least 

30 one complementary pair of routines 4/4' or 5/5', such that in 
each case it contains the assigned deinstallation or 
deconf iguration routine 4', 5' for the installation or 
configuration routine 4, 5. 

It will be understood that the four routines 4, 4', 5 and 

35 5' , where they have common portions of code, may also in part 
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be combined to form a common routine^ for example a commonly 
run introductory routine of the rule package RP, or may 
overall be implemented by a common portion of code which is 
controlled by appropriate call switches, on one occasion for 
5 example functioning as the installation routine 4, on another 
occasion for example functioning as the deconf iguration 
routine 5', etc.. In this respect, routines 4, 4', 5, 5' are 
"functional" routines, not necessarily routines in the 
software engineering sense, as is clear to the person skilled 
10 in the art. 

In the present description, the term "installation" is 
used to denote the fundamental provision of the possibility of 
using a software component on a client computer. Installation 
generally includes storage of the software component A on a 

15 local data storage medium (for example the hard disk) of the 
client computer, and frequently also an initial, general 
configuration (see below) of the software component to ensure 
that it . is fundamentally operable. Installation may also 
include one or more rules for automatically supplementing or 

20 modifying the stored software component A by means of provided 
updates . 

The term "deinstallation" is used to denote the removal of 
the software component SW from the client computer 2, for 
example by deletion from the hard disk. 

25 The term "configuration" is in turn used to denote any 

kind of standard, group-specific, user-specific or 
application-specific setting of a software component, as 
symbolised by the setting arrow in Fig. 2. The method 
according to the invention thus not only enables the 

30 autonomous installation of all necessary software components 
on a client computer, but also the setting of a specific 
state, defined in the framework FW, of these software 
components . 

In the present description, the phrase "undoing a 
35 configuration" or "deconf iguring" is taken to mean the 
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recreation of the particular setting of a software component 
as prevailed before the configuration, and/or setting the 
other software components remaining behind after 
deinstallation of this software component in a manner which is 
5 required for the current system state without the deinstalled 
software component; the latter is also the intended meaning of 
the phrase undoing the configuration "with regard to" this 
software component . 

According to Fig. 4, the rule package RPa may optionally 

10 contain one or more trigger references TRIGa to a local or 
remote event, on the occurrence of which at least one of its 
routines 4, 4', 5, 5' should be executed, as is explained in 
greater detail below with reference to Fig. 9. 

The rule package RPa may also comprise local resources 

15 RES4, RES5 for example small software components or 
configuration parameters. 

Each of routines 4 , 4' , 5, 5' contains an independent 
verification of the prerequisites for the installation, 
configuration, deinstallation or deconf iguration of the 

20 software component assigned to the rule package, for example 
the requirement for the presence of another software component 
("require" paths in Fig. 5) or the absence of a component 
("restrict" paths in Fig. 5) . If the particular routine 
establishes a presence requirement ("require"), it calls the 

25 installation routine 4 of the other rule package RP assigned 
to this other software component; if it establishes an absence 
requirement ("restrict"), it calls its deinstallation routine 
4' . In this way, the interrelationships of Fig. 5 are 
maintained and executed by running the rule packages. 

30 Obviously, this verification may also be relocated to a part 
of the rule package which is common to the routines and which 
is always run on execution of a routine. 

In order to simplify the verification of the presence or 
absence of a specific software component, the framework FW 

35 comprises a set of detection routines or detectors DET, for 
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example a detector DETa for the presence of the software 
component A, a detector DETbsi for the presence of the 
operating system component BSl or a detector DEThw for the 
presence of specific hardware on the specific client computer 
5 2, see Fig. 5. 

The detectors DET may not only verify the presence or 
absence of a software component SW, but also whether a 
software component is currently running or being executed or 
not. In the present description, all these variants are 

10 jointly denoted by the phrase "presence or absence" or are one 
of the possible prerequisites for a software component which a 
detector DET can verify. 

The detectors DET may also call one another or make use of 
one another, for example if a prerequisite to be verified may 

15 be broken down into a plurality of individual prerequisites, 
for which other detectors are already present. 

Appendix 1 shows an example of implementation of a 
detector for establishing the presence of the software 
component "Microsoft Word 10.0" from Microsoft. The 

20 "query_exist" subroutine verifies the presence of the software 
component; the "query_active" subroutine verifies whether the 
software is running. 

Each of routines 4, 4', 5, 5' may advantageously be 
designed such that it itself verifies or verifies by means of 

25 corresponding detectors DET whether it is suitable for the 
hardware or software found on the client computer 2 and, if 
not, is for example terminated without further action, i.e. 
returns control. The routine may also verify whether the 
called installation, deinstallation, configuration or 

30 deconf iguration of its software component has not already 
occurred, in which case it is likewise terminated, i.e. 
returns control. Alternatively, these checks may however also 
be relocated to a portion of code of the rule package RP which 
is common to the routines (see above) or to the calling 

35 process P (see below) . 
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Finally, the framework FW comprises a list L of those rule 
packages RP which should be run first in the client computer 
2. It will be understood that the list L may, for example, 
refer only to the first rule package RP, which recurses into 
5 further rule packages RP, or may simply list all rule packages 
RP, if the latter in each case themselves establish the 
prerequisites for their execution, or may alternatively list 
only those rule packages which are specified by an 
administrator as a "thought for the day" etc.. 

10 In a preferred implementation, a rule package RP consists 

of a set of files which are referenced by a central rule 
package specification file. An example of such a rule package 
specification file is shown in Appendix 2. The reference to 
the software component can be seen in the header portion of 

15 the file; the references "install", "uninstall", 
"policies_true" and "policies_f alse" point respectively to the 
four routines 4, 4', 5 and 5'. 

Evaluation of the framework FW and running of the rule 
packages RP on the client computer 2 is carried out with the 

20 assistance of a client program KP, which carries out the 
described running of the list L in a process P (Fig. 2) . To 
this end, the client program KP contains a storage means S for 
local storage of a copy of the framework FW, which may also be 
used for the further distribution (replication) of the 

25 framework FW on other client computers 2. 

The client program KP further has a local database DB 
which keeps two lists 7, 8, the of use which is shown in 
greater detail in Figs. 7 and 8. The first list 7 contains an 
entry for each rule package RP whose installation routine 4 

30 has been run successfully. The second list 8 contains an entry 
for each rule package RP whose configuration routine 5 has 
been run successfully. The client program KP accordingly has a 
record of all the software components SW which have been 
successfully installed and configured on the client computer 

35 2, which record may also be used when running the rule 
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packages RP to identify and avoid double calls or endless 
recursions. The local database DB is also of use in 
identifying and removing obsolete or outdated software 
components, as is thoroughly explained in the context of the 
5 flow chart of Fig. 6. 

Fig. 6 shows an example flow chart for the client program 
KP. After initialisation in block 9, in block 10 all the rule 
packages RP listed in list L of the framework FW are run, 
specifically by calling their installation routines 4. It will 
10 be understood that if, in so doing, the rule packages RP 
establish by means of the detectors DET the prerequisite of 
presence or absence of other rule packages RP, they will in 
each case recurse into these other rule packages, as already 
explained. 

15 Once all the installation routines 4 have been run in 

block 10 and thus all the necessary software components BSl, 
A, B, etc. have been installed on the client computer 2, the 
client program KP or its process P passes over to block 11, in 
which the software packages are configured in a second pass 

20 through the list L. In block 11, the rule packages RP listed 
in list L are run again, but this time calling their 
configuration routine 5. If necessary, the rule packages RP 
may again recurse into further rule packages, as already 
explained. 

25 Because a complete installation of all necessary software 

components initially proceeds in block 10, it is ensured that 
configuration in block 11 starts from a defined system state 
which in many cases is essential for correct configuration. 

The further blocks 12 and 13 of the method or of the 

30 client program KP shown in Fig. 6 are optional and serve to 
eliminate obsolete or outdated software components from the 
client computer 2. 

As already mentioned, rule packages RP for obsolete or 
outdated software components are no longer contained in the 

35 framework FW, but may nevertheless still be necessary on a 
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client computer 2, for example due to outdated hardware. The 
client program KP accordingly compares the rule packages RP 
contained in the framework FW with the. rule packages RP 
entered in lists 7 and 8 of the local database DB and puts 
5 those rule packages RP, which no longer appear in the 
framework FW, in an inactive state, for example by an 
appropriate flag in lists 7 and 8 or in the rule package RP 
itself. When in the inactive state, a rule package RP can only 
any longer be called by means of its deinstallation routine 4' 
10 or its deconf iguration routine 5' . 

In block 12, all inactive rule packages RP are called by 
means of their deconf iguration routines 5' - In the following 
block 13, another pass proceeds through their deinstallation 
routines 4' . 

15 As already explained, each deinstallation or 

deconf iguration routine (or also the process P) checks whether 
it is usable on its "target", the client computer 2, and only 
if this is possible (for example removal of outdated 
hardware), is it executed. On deconf iguration or 

20 deinstallation, it then also in each case deletes itself again 
from list 7 or 8 of the local database DB. 

In this way, each pass of the client program KP involves 
execution of a kind of "cleaning" pass which eliminates 
outdated or obsolete software components and their rule 

25 packages. 

In block 14 of the flow chart of Fig. 6, completion 
processes are carried out and the client program KP 
terminated. 

Execution of the client program KP on the client computer 
30 2 may be initiated in many different ways. Fig. 9 shows some 
possible variants. Upstream from the run process P of the 
client program KP there is an event manager 15 which can 
process both local events on the client computer 2 and remote 
events, for example at the maintenance workstations 3. 
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Some kinds of local events 2 are represented symbolically, 
for example user events 16 such as pressing an appropriate 
key, system events 17 such as identification of a system 
startup or shutdown, user logon or logoff, network logon or 
5 logoff, program startup or shutdown etc., hardware events 18 
such as connection or disconnection of hardware, or local 
events 19 defined by the system administrator. It is, however, 
also possible for the client program KP to be triggered by 
remote events, for example by active transmission of a trigger 

10 command from a maintenance workstation 3, or by "passive" 
retrieval of a trigger command from a network resource RESi, 
for example in the course of a network logon or at 
predetermined times of day. 

The stated events may also directly trigger the execution 

15 of specific rule packages RP or routines 4, 4', 5, 5', 
specifically by means of their trigger references TRIG (see 
Fig. 4) . The event manager 15 of the client program KP may 
directly call the rule packages or routines assigned via the 
trigger references TRIG, or via lists 7, 8 of the local 

20 database DB, in which the rule packages RP have entered their 
trigger references TRIG. It is also possible in block 9 of the 
client program KP, after triggering of the event manager 15, 
to preselect those rule packages, in accordance with their 
trigger references TRIG, which correspond to the event trigger 

25 of the event manager 15, and then to run the client program 15 
only for these preselected rule packages RP. 

Another possibility is to use the trigger references TRIG 
in the rule packages RP as a "filter" for running the rule 
packages in the course of event-controlled execution of the 

30 client program KP: if a rule package contains at least one 
trigger reference TRIG, when called by the client program KP 
it is executed only if its trigger reference TRIG also 
corresponds to this event. 

Fig. 10 shows an implementation example of the client 

35 program KP in the context of an operating system of a client 
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computer 2, which provides protected domains ("contexts") for 
individual processes, for example in order to isolate user 
processes from system processes and so enhance operating 
stability. Since software component installation and 
5 configuration often require cross-context permissions, the run 
process P is here subdivided into several execution engines Pi, 
Pa and P3 running in protected system domains "Admin", "User" 
and "System". 

For each system-modifying component of the method, for 
10 example the routines of the rule packages, it is possible to 
implement a transaction system which enables complete rollback 
of the system configuration should the installation, 
deinstallation, configuration or decohf iguration of a software 
component fail. 

15 The invention is not limited to the stated embodiments but 

instead includes all variants and modifications which fall 
within the scope of the attached claims. 
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APPENDIX 1 

[snil::header] 
smlversion=3.0.0 
encoding=iso8859- 1 
5 type=dsf 

objectid=3 -A 1 1 - 1 OOA-5 7F0- 1 OOOCOOOOO 1 -0-0 
sqn=3-FFFF-100A-57F0-25-0-0 
name=Microsoft Office XP Premium Edition 

10 [dsf::query_exist] 

/* detect Office 10.0 components */ 
if.reg.keyexist conditionrtrue,- 

>reghive=HKEY_^LOCAL_MACHINE.regpath=SOFTWARE\Microsofl\Office\10,0, 
{ 

1 5 do.reg.setkey 

regkeyhandle:hRegistry,reghive=HKEY_LOCAL_MACHINE,regpath=SOFTWAR^ 
\InstallRoot,option=OPEN, 

if.sys.handleisvalid condition :true regkeyhandleihRegistry, 

{ 

2 0 ;detect WinWord 

;flrst let's see if the required file exists 
if.file.exist condition:false5-> 

.->filepath=<!--get.reg. value regkeyhandle:hRegistry,->regentiy=Path,--!>WINWORD.EXE, 
{ 

2 5 do.sys.exit->leveI=section,retumvalue=faIse, 

} 

;second let's check the files required property 
if.file.matchversionproperty condition:faIse,-> 

.->filepath=<! -get. reg. value regkeyhandle:hRegistry,->regentry=Path,—!> WIN WORD, EXE, 

3 0 .->propertyname=fileversion5 versionproperty type:eq5= 10.*, 

{ 

do.sys.exit->level=section,retumvalue=false, 

} 

do.sys.closehandle regkeyhandie:hRegistry, 

35 } 
} 

[dsf: :query_active] 

/♦ dedect if Office 10.0 WinWord component is running */ 

4 0 if.reg.keyexist condilionrtrue,- 

>reghive=HKEY_LOCAL_MACHINE,regpath=SOFTWAREVMicrosomOffice\10.0, 
{ 

do.reg.setkey 

regkeyhandle:hRegisti7,reghive=HKEY_LOCAL_N4ACHINE,regpath=SOFTWARE\M 

4 5 \InstallRoot,option=OPEN, 

if.sys.handleisvalid condition: true regkeyhandle:hRegistry, 

{ 

;dedect WinWord 

if.process.exist condition:false,->processname=WINWORD.EXE, module=<!~getreg. value 

5 0 regkeyhandle:hRegistry.->regentry=Path.-!>WINWORD.EXE. 

{ 

call.sys.exit->level=section.retumvalue=false, 

} 

call.^s.closehandle regkeyhandle:hRegistry. 

55 } 
} 
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APPENDIX 2 

[snil::header] 
srnlversion=3.0.0 
encoding=iso-8859-l 
5 type=psf 

obj ectid=3-3F 1 - 1 OOA-5 7F0- 1 OOOCOOOOO 1 -0-0 
sqn=3-FFFF- 1 00A-57F0-2-0-0 
name=Microsoft Office XP Premium 

10 [psf::defmition] 

packagename->text=Microsoft Office XP, 

packagedescription->text=The Microsoft Office XP Premium Suite, 
packagecompany->text=Microsoft, 

packagecopyright->text=Copyright© Microsoft Corporation 1985-2001. All rights reserved., 
1 5 packageproductversion-> versionnumber= 1 0.0, 
packagedate->text=2002-0 1-01, 

[sml::system] 

transactioncontext->context=package, 
2 0 securitycontext->context=ADM, 
oscontext->context=Win32, 

[sml::ossupport] 

windowssys->platform=x86,os=nt,osversion type:=,=5.0,sp type:>=,=3, 
2 5 windowssys->platform=x86,os=ntosversion type:==,=5. 1 ,sp type:>=,= 1, 

winesys->platform=x86,wineversion type:>=,=2.0.0,winetype=CROSSOVER_OFFlCE, 

[psf::detectself| 

detectsoftware->objectid=3- A 11-1 00A-57F0- 1 OOOCOOOOO 1 -0-0, 

30 

[smi : rdisplaysupport] 
display->show=l, 

displayheader->text=Microsoft Office XP, 
displaytext->text=Manages Microsoft Office XP..., 

35 

[psf::archive] 

archivepolicies->archive= 1 ,override= 1, 
archiveuninstali->archive= 1 , 

4 0 [psf : :instailoptions] 

ro!lbackonerror->rollback= 1 , 

installevents->event=ALL5 
ownersonly->restrict=0, 

4 5 [psf: :dedecttargets] 

if.group.accountismember->groupname groupformatrdefault, type:eq,=officexp, 

[psf::install] 

instal ljobid->objectid=3-4 11-1 OOA-5 7F0- 1 OOOCOOOOO 1 -0-0. 

50 

[psf::uninstall] 

uninstalljobid->objectid=3-44 1 - 1 00A-57F0- 1 OOOCOOOOO 1 -0-0, 

[psf: :policies_true] 

5 5 policyid->objectid=3-47 1 - 1 00A-57F0- 1 OOOCOOOOO 1 -0-0, 

[psf::policies_false] 
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policyid->objectid=3-47 1 - 1 00A-57F0- 1 OOOC000002-0-0 



